Currently, when internal pipelines build for ARM64X we use the older
experimental `MSVC_BUILD_AS_X` feature. The latest VS release has
regressed this functionality, resulting in the import libs for the ARM64
and ARM64X DLLs being written to the same location.

Remember that ARM64X binaries are fat binaries containing both ARM64 and
ARM64EC code. When building for ARM64 with MSVC_BUILD_AS_X, the Visual
Studio cmake generator actually generates vcxproj files that build ARM64
and ARM64EC (with the ARM64EC version being the one that becomes the
combined ARM64X binary. The generated project knows how to ensure that
the ARM64 DLL is built to one location and the ARM64X one goes into the
destination specified in the cmake scripts. However, the import
libraries end up being configured to go into the same location,
resulting in a race condition.

Our cmake scripts have no knowledge of these two platforms, and so
there's no direct way to address this. This workaround makes it so that
when building in this mode the import libraries are written to a
location containing `$(PLATFORM)`. This is a msbuild variable that's
evaluated at build time.

This is a short-term fix that allows us to unblock our internal
pipelines. Longer-term we should move to using the [documented ARM64X
approach](https://learn.microsoft.com/en-us/windows/arm/arm64x-build#building-an-arm64x-dll-with-cmake),
at which point this change should be reverted.

(cherry picked from commit ea7e910)

Previous version used type erasure through a `void* (*)()` pointer,
which triggered gcc warning and implied a lot of reinterpret_cast.

This version should make it harder to hit ourselves in the foot.

Differential revision: https://reviews.llvm.org/D54203

(cherry picked from commit 86f8b70f1b7c3f92266197d580f6d86414650997)
(cherry picked from commit 4ddee81)